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tributed data processing system, and the client process 
requests a remote procedure call for a service procedure. A 
binding handle of a server process is obtained; a determi- 
nation is made as to whether the binding handle of the server 
process points to the client process; and in response to a 
determination that the binding handle of the server process 
points to the client process, a positive indication is generated 
that the service procedure is provided by the client process. 
In response to a determination that the service procedure is 
provided by the client process, the service procedure is 
called using a local procedure call after obtaining a local 
address for the function within the client process by looking 
up the service procedure in an interface registry, 
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FIG, 6A 

\i (9_selfcall) 

CSPEILselfcall( fid,&BELhandleJnfo.p_interface, 

p_operation, op_num, iccomrrustaLinfo, &foulLstoLinfo): 



FIG. 6B 

CSPELLmanager.selfcQlI( fid, P_interface, P_operation, 

rep_as_handle_param,rep_as_type_nQme, 
binding_hondle_name); 



FIG. 6C 

/♦SELFCALL START*/ 
TRY 

selfcall = rpc_check_selfcall( (rpc_binding_hondle_t) handle, 

(rpc_if_handle«t) &IDLifspec, 
&IOL.mgr_epv); 

if (selfcall) 
1 

Rpc.binding_clienLfrom_server{ (rpc_binding.handle_t) hondle, 

(rpc„binding_handle_t) clienLhandle, 
icstatus); 

if (status = = error_status_ok) 

I 

/♦this is the coll to the monoger code, which con be different for every interface ♦/ 
(»((intf1_v2»0_epv_t*)IDl_mgr_epv)->functionl)(clienLhandle,parm1,porm2); 

else selfcall = FALSE; 

} 

CATCH_ALL . 

if (exc_geLstatus_(THIS_CATCH,(SclOL-ms. IDL_status) 1 =error_status_ok) 

IOLms.lDL.stotus=rpc_s_faulLunspec; 
ENDTRY 

if (clienLhondle) rpc_binding_free(clienLhondle.(Scstotus); 
if (self.call) gotolOl^closedown; 

/♦SELFCALLENO*/ 
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METHOD AND SYSTEM FOR CONVERTING 
A EUEMOTE PROCEDURE CALL TO A 
LOCAL PROCEDURE CALL WHEN THE 
SERVICE IS ON THE SAME DEVICE AS 
THE CALLING CLIENT 

BACKGROUND OF THE INVENTIGN 

1. Technical Field 

The present invention relates generally to an improved 
data processing system and, in particular, to a method and 
apparatus for interprocess or intraprocess communication, 
specifically remote procedure calling. 

2. Description of Related Art 

It is known in the art to interconnect multiple computers 
into a local area network (LAN) to enable such computers to 
exchange information and share resources. A local area 
network provides a distributed computing environment in 
which users can access distributed resources and process 
applications on multiple computers. Network communica- 
tions are carried out using so-called communication proto- 
cols. By convention, communication architectures in a local 
area network are typically characterized as conforming to a 
seven layer model in the following hierarchy: physical layer, 
logical link layer, network layer, transport layer, session 
layer, presentation layer and application layer. The physical 
layer comprises the actual physical devices and medium 
used to transmit information. The logical link layer frames 
data packets and controls physical layer data flow, insuring 
delivery of data regardless of the actual physical medium. 
The network layer addresses and routes data packets. It 
creates and maintains a route in the network between a 
source node and a destination node. The transport layer 
creates a transport pipeline between nodes and manages the 
network layer connections. The session layer typically pro- 
vides remote procedure call (RPC) support, maintains the 
integrity of the connection between nodes and controls data 
exchange. The presentation layer encodes and decodes data 
and provides transparency between nodes. Finally, the appli- 
cation layer provides the interface to end-user processes and 
provides standardized services to applications. 

The seven layer model has many variations depending on 
the particular network architecture. Thus, for example, in a 
network architecture based on the TCP/IP (Transmission 
Control Protocol/Internet Protocol) interface running IBM 
RISC System/6000^" computer workstations under the AIX 
Operating System, there is another layer, called the socket 
layer, that sits between the session and transport layers. The 
socket layer creates 'so-called "sockets" which are logical 
constructs analogous to physical ports. In this architecture, 
the RPC mechanism is not just supported in the session 
layer, but also includes functionality of the session layer. 

Remote procedure call is the foundation of modern client- 
server based distributed systems. One well-known distrib- 
uted system that uses RPC as the basic communication 
mechanism is Microsoft's DCOM (Distributed Component 
Object Model). The best-known application using RPC in 
the Unix worid is Sun*s NFS (Network File System), which 
is based on their ONC (Open Network Computing) RPC. In 
addition, most of the. ORB (Object Request Broker) imple- 
mentations of the OMG's (Object Management Group) 
CORBA (Common Object Request Broker Architecture) 
specifications build their remote method calls for object 
communications on top of a variation of RPC. 'ITie Java RMI 
(Remote Method Invocation) is another variation of the RPC 
technology. 
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A known RPC mechanism useful in Distributed Comput- 
ing Environments (DCE) includes software code provided 
by the Open Systems Foundation (OSF). The OSF DCE 
RPC mechanism is used conventionaUy to manage commu- 

5 nication between a "client*' and a "server** in a distributed 
computing environment, with the client requesting a service 
from a server using a remote procedure call (RPC). A 
"client" refers to a network participant that is requesting a 
service accessible somewhere within the computing envi- 
ronment. A "server" provides the requested service to a 
client. With the OSF DCE RPC mechanism, each client 
process (namely, a process running on a client machine) has 
an associated socket created by the socket layer. Each server 
process likewise is associated with a socket. In response to 
an RPC, a call directory service returns a data structure, 
called a "binding handle," specifying the location of the 
server process as a network address and the port number 
where the server process is running. The binding handle is 
then used by the RPC mechanism to define a communication 
path between the client process and the server process. The 
path is defined using IP-based (i.e., network layer) protocol 
sequences of the Internet Network Address Family (AF„ 
INET) to open the sockets. The path loops down from the 
client process through the transport and network layers, out 
on the network and then back up the layers associated with 
the host on which the server process is running. 

Due to its role in distributed processing, RPC is a key 
factor in the overall performance of a distributed system. 
There have been various techniques proposed and imple- 

3Q mented to improve RPC performance. For example, RPC 
stubs on both the client side and the server side require a 
large amount of memory space and large storage space. In 
U.S. Pat. No. 5,778,228, "Method and System for Transfer- 
ring Remote Procedure Calls and Responses Over a 

35 Network", a method is disclosed for optimizing the RPC 
stub routines so as to significantly reduce their impact on 
system memory and mass storage. 

As another example of the need for RPC optimization, the 
OSF DCE RPC mechanism as described above cannot 

40 distinguish whether client and server processes are running 
on the same host machine. In all cases, the mechanism 
returns a binding handle to the chent process including an 
AF_INET protocol sequence that sets up a communication 
path through the transport (TCP or UDP) layer and the 

45 network (IP) layer. Communications through TCP use 
connection-oriented protocol sequences while those through 
UDP use connectionless protocol sequences. But in either 
case, when the client and server processes reside on the same 
host, an RPC generates a so-called loopback message 

50 because once the network (IP) layer receives the destination 
network address, it recognizes that the RPC is "local"; the 
path must therefore be looped back up through the transport 
layer to the server process on the apphcations layer. Because 
of this loopback requirement, RPCs between client and 

55 server processes on the same machine are not optimized 
from a performance standpoint as they use the transport and 
network layers unnecessarily. 

In U.S. Pat. No. 5,682,534, "Transparent Local RPC 
Optimization", a method is disclosed for bypassing heavy- 

60 weight transport stack operations using local sockets for 
interprocess calls on the same machine. However, this 
method still incurs a significant amount of processing over- 
head for local socket operations and for parameter marshal- 
ling and unmarshalling. 

65 Therefore, it would be advantageous to have an improved 
method and system for optimizing RPCs by completely 
bypassing RPC setup when possible. 
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SUMMARY OF THE INVEISfTION 

A method and system for optimizing remote procedure 
calls by converting the remote procedure call to a local 
procedure call is provided. A client process resides on a host 
computer within a distributed data processing system, and 
the client process requests a remote procedure call for a 
service procedure. A determination is made as to whether the 
service procedure is provided by the client process in the 
following manner: a binding handle of a server process for 
the service procedure is obtained; a determination is made as 
to whether the binding handle of the server process points to 
the client process; and in response to a determination that the 
binding handle of the server process points to the client 
process, a positive indication is generated that the service 
procedure is provided by the client process. In response to 
a determination that the service procedure is provided by the 
client process, the service procedure is called using a local 
procedure call after obtaining a local address for the function 
within the client process by looking up the service procedure 
in an interface registry. The conversion of the remote 
procedure call to a local procedure call is performed within 
client stub code for the service procedure within the client 
process. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further objec- 
tives and advantages thereof, will best be understood by 
reference to the following detailed description of an illus- 
trative embodiment when read in conjunction with the 
accompanying drawings, wherein: 

FIG, 1 is a pictorial representation of a distributed data 
processing system in which the present invention may be 
implemented; 

FIG. 2 is a block diagram depicting a data processing 
system that may be implemented as a server; 

FIG. 3 is a block diagram depicting the apparent com- 
munications provided by an exemplary remote procedure 
call in terms of the actual communication that occurs 
between the client and the server; 

FIG. 4 depicts actions within a typical IDL compilation 
environment; 

FIG. 5A is a flowchart depicting a process for generating 
code for the selfcall mechanism during IDL compilation in 
accordance with a preferred embodiment of the present 
invention; 

FIG. 5B is a flowchart depicting a process for executing 
code in the client process that is capable of implementing the 
selfcall mechanism in accordance with a preferred embodi- 
ment of the present invention; 

FIG. 5C is a block diagram depicting a conversion of a 
remote procedure caQ to a local procedure call within a 
single process space; 

FIG. 6 A is a source code statement depicting a routine 
within the IDL compiler that has been enhanced to accept a 
selfcall option and generate the code to check whether 
selfcall is supported in accordance with a preferred embodi- 
ment of the present invention; 

FIG. 63 is a source code statement depicting a routine 
within the IDL compiler that has been enhanced to generate 
the code to make the manager function call in accordance 
with a preferred embodiment of the present invention; and 

FIG. 6C is a set of source code statements that provide 
information about the changes that may be made to the client 
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Stub code to incorporate the selfcall mechanism of the 
present invention. 

DETAILED DESCRIPTION OF THE 
5 PREFERRED EMBODIMENT 

Distributed Computing Environment 

With reference now to the figures, FIG. 1 depicts a 
pictorial representation of a distributed data processing 
system in which the present invention may be implemented. 
Distributed data processing system 100 is a network of 
computers in which the present invention may be imple- 
mented. Distributed data processing system 100 contains a 
network 102, which is the medium used to provide commu- 
nications links between various devices and computers 
connected together within distributed data processing sys- 
tem 100. Network 102 may include permanent connections, 
such as wire or fiber optic cables, or temporary connections 
made through telephone connections. 

20 In the depicted example, a server 104 and server 106 is 
connected to network 102 along with storage unit 108. In 
addition, clients 110, 112, and 114 also are connected to 
network 102. These clients 110, 112, and 114 may be, for 
example, personal computers or network computers. For 

25 purposes of this application, a network computer is any 
computer, coupled to a network, which receives a program 
or other application from another computer coupled to the 
network. In the depicted example, server 104 provides data, 
such as boot files, operating system images, and applications 

30 to clients 110-114. 

Clients 110, 112, and 114 are clients to server 104. 
Additionally, clients 110-114 also may be clients to server 
106 in these examples. Distributed data processing system 
100 may include additional servers, clients, and other 

35 devices not shown. In the depicted example, distributed data 
processing system 100 is the Internet with network 102 
representing a worldwide collection of networks and gate- 
ways that use the TCP/IP suite of protocols to communicate 
with one another At the heart of the Internet is a backbone 

40 of high-speed data commimication lines between major 
nodes or host computers, consisting of thousands of 
commercial, government, educational, and other computer 
systems that route data and messages. Of course, distributed 
data processing system 100 also may be implemented as a 

45 number of different types of networks, such as, for example, 
an intranet, a local area network (LAN), or a wide area 
network (WAN). 

FIG. 1 is intended as an example and not as an architec- 
tural limitation for the present invention. The present inven- 

50 tion is applicable to all client-server distributed systems 
which use remote procedure calls or a variation of remote 
procedure call as a foundation for communications among 
clients and servers. 

55 Hardware Platform Description 

With reference now to FIG. 2, a block diagram depicting 
a data processing system that may be implemented as a 
server, such as server 104 or server 106 in FIG. 1. Data 
processing system 200 may be a symmetric multiprocessor 

60 (SMP) system including a plurality of processors 202 and 
204 connected to system bus 206. Alternatively, a single 
processor system may be employed. Also connected to 
system bus 206 is memory controller/cache 208, which 
provides an interface to local memory 209. I/O bus bridge 

65 210 is connected to system bus 206 and provides an interface 
to I/O bus 212. Memory controller/cache 208 and I/O bus 
bridge 210 may be integrated as depicted. 
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Peripheral component interconnect (PCI) bus bridge 214 which unmarshalls the parameters and passes the request to 

connected to I/O bus'212 provides an interface to PCI local server 304 via return 334. Server 304 now carries out the 

bus 216. A number of modems may be cotmected to PCI bus requested action. 

216. Typical PCI bus implementations will support four PCI The result is returned to the client by reversing the entire 

expansion slots or add-in connectors. Communications links 5 process. In particular, server 304 makes call 336 to server 

to network computers 108-112 in HG. 1 may be provided stub 332 to return the result. Server stub 332 marshalls the 

through modem 218 and network adapter 220 connected to parameters and makes call 338 to RPC runtime procedure 

PCI local bus 216 through add-in boards. 328. This results in RPC runtime procedure 328 making call 

Additional PCI bus bridges 222 and 224 provide inter- 340 to network interface 324. It is network interface 324 that 

faces for additional PCI buses 226 and 228, from which 10 sends the actual reply message 342 to network interface 320 

additional modems or network adapters may be supported. on the client, which, in turn, passes the reply to RPC runtime 

In this manner, data processing system 200 allows connec- procedure 316 via return 344. RPC runtime procedure 316 

tions to multiple network computers. A memory-mapped passes the reply on to client stub 312 via return 346, which 

graphics adapter 230 and hard disk 232 may also be con- unmarshalls the parameters and passes the reply to client 

nected to I/O bus 212 as depicted, either directly or indi- is 302 via return 348. Client 302 now has the result of the 

recti y. requested action. 

Those of ordinary skill in the art will appreciate that the The Interface Definition Language (IDL) is used to 

hardware depicted in FIG. 2 may vary. For example, other specify client -server interfaces in a language independent 

peripheral devices, such as optical disk drives and the like, fashion. There is an IDL compiler that translates this lan- 

also may be used in addition to or in place of the hardware guage independent specification into an actual target lan- 

depicied. The depicted example is not meant to imply guage on a particular server machine. To understand how 

architectural limitations with respect to the present inven- RpC optimization is accomplished, it is necessary to review 

tion. The data processing system depicted in FIG. 2 may be, the compilation steps necessary to produce the client runt- 

for example, an IBM RISC/System 6000''"" system, a prod- ime code and the server runtime code, 

uct of International Business Machines Corporation in 25 with reference now to FIG, 4, actions within atypical IDL 

Armonk, N. Y., running the Advanced Interactive Executive compUation environment are depicted. The generation of the 

(AIX"^") operating system. client runtime code is discussed first. Client source code 402 



Remote Procedure Call (RPC) Description 



needs to know about the client-server interface and the 
runtime code for the remote procedure call. The client-server 

In the modern world of networked, heterogeneous com- interface is specified in Interface Definition Language File 

puting systems, the task of communications between clients 404, IDL compilation action 406 opens IDL file 404 and 

and servers is quite Icomplex. There are a variety of proto- translates the specification into the target language. In FIG. 

cols for registering service requests. One of the most widely 4, the target language C is shown, so header files 408 and 

used techniques is a remote procedure call (RPC). client stub source code 410 are produced. Compilation 

FIG. 3 and FIG. 4 provide background information for an action 412 combines client stub source code 404 and headers 

example RPC mechanism. A DCE client application imports 408. Compilation action 414 combines client source code 

one or more RPC interfaces. The client accesses the server 402 and headers 408. Linking action 418 combines RPC 

services by making RPCs on the operations defined in the runtime source code 416 with the results of compilation 

RPC interface exported by the server. An IDL compiler action 412 and compilation 414 to produce client runtime 

generates client stub routines and server stub routines to code 420. 

process data for the remote procedure call operations. A stub The server runtime code is produced in a manner similar 

routine is a program module that transfers remote procedure to the client runtime code. Specifically, IDL compiler 406 

calls and responses between a client and a server. uses IDL file 404 to produce server stub source code 426 and 

With reference now to FIG, 3, a block diagram depicts the 45 header files 424. Compilation action 430 combines server 

apparent communications provided by an exemplary remote source code 422 with header files 424. Compilation action 

procedure call in terms of the actual communication that 428 combines server stub source code 426 with header files 

occurs between the client and the server. The client pro- 424, The results of compilation actions 428 and 430 are then 

cesses are shown on the left side of the figure, and the server combined with RPC runtime source code 416 by hnking 

processes are shown on the right side of the figure. 50 action 432 to produce server mntime code 434. 

In the apparent communication paths of a remote proce- As one of ordinary skill in the art will appreciate, the 

dure call, client 302 requests a service from server 304 via compilation steps shown in FIG. 4 using C could easily be 

a call to service procedure 306. Server 304 carries out the adapted to use other languages, such as C++ or Java. The 

invoked procedure and returns result 308 to client 302. client code and server code produced by this compilation 

Assuming the client and server are on different machines, 55 process contain all the overhead necessary to run in a 

the actual communications process during a remote proce- distributed environment with the client and server on dif- 

dure call is more complex. Client 302 makes call 310 to ferent machines. As one of ordinary skill in the art will 

client stub 312 requesting the service to be performed. Client appreciate, there is a great deal of overhead processing that 

stub 312 marshalls the parameters for the call, that is, is needed to give the appearance that a client can request a 

assembles the parameters into the proper format, and client 60 service from a server and receive a reply from the request, 

stub 312 makes call 314 to RPC runtime procedure 316. This This entire chain of events is necessary when the client and, 

results in RPC runtime procedure 316 making call 318 to server are on difi[erent machines in a distributed computing 

Network interface 320, which sends an RPC request mes- environment. 

sage via some network protocol. Network interface 324 on When processing requests in modularized distributed 

the server, in turn, passes the request to RPC runtime 65 systems, such as process-based software (e.g., DCE 

procedure 328 via return 326, RPC runtime procedure 328 applications), object-based software (e.g., ORB 

passes the request on to server stub 332 via return 330, applications), or component-based software (e.g.. Enterprise 
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Java Beans or EJBs), a software module may invoke a references to these parameters are returned to the client. The 

service that is actually provided by itself. This situation RPC mechanism accomplishes a local-remote transparency 

causes a call to a service exported from itself. The DCE successfully in this case: the parameters are marshalled (and 

Security server frequently does such self-service requests. copied) into linear buffers, and the parameter memory and 

If the client and the server are on the same machine, then 5 the buffers are deaUocated after the buffers are sent back to 

an ordinary procedure call could accomplish the same result ^TTul^n^^^'u [f^^^^^^S/^^ ^"^P^^ 

as the remote procedure call mechanism. Tlie key idea of this P^J^^te^^^ ^^e client RPC stub allocates the parameter 

. . / . t. 1- . J memory from the cnent process heap and copies the par am- 

invention is to recognize when the chen and server are on ^^^^ ^^^^^ ^^^^^ ^^^J^ demonstrates the 

the same machine and running as part of the same process. behavior as the local procedure caU. 

In this mvention, the compilation process is altered so that lo 3^ Input-and-output Reference Parameters 

the code produced for the client and the server uses an in this case, the RPC client has an input parameter that 

ordinary procedure call in place of a remote procedure call points to structures in the client process heap. The parameter 

if the client and server are on the same machine. is passed in the call to the procedure and also returned from 

the call. In local procedure calls, the same memory is passed 

Selfcall Techmque 15 over to the procedure and passed back, with the possibility 

The present invention introduces an RPC optimization of ^^^ing altered by references to the substructures by the 

scheme called "selfcall" that will completely bypass the procedure. The RPC mechanism implements local-remote 

RPC parameter marshalling/unmarshalUng and the transport transparency well in this case, where the output parameter as 

stack altogether for those RPCs that qualify. A selfcall can changed at the return of the procedure will reflect correctly 

occur when an RPC is to be made to a service provided by ^^^^ "^^^^ ^^^^^^ ^^^^ 

the same server in which the RPC caller resides. This , r 

condition is seen in core infrastructure servers such as the j^^r^'^y Reference Paranneters 

DCE's security server. The selfcall techniques can be appli- , ^his is a case where the local-remote transparency may be 

cable to all variations of RPC including remote object broken if the server procedure alters the mput parameters. In 

invocations in ORBs, Java RMI, and the MS DCOM pro- RPC, input-only reference parameters will not be returned 

cessing. Rather than performing a remote procedure caU, the ^""^ the server: the changes, if any. made by the procedure 

caller can turn around to invoke the procedure directly via ^" f ^" the client. In a local procedure call, the 

the normal procedure call mechanism instead of RPC. changes made to the reference parameters are always visible 

Beyond by-passing the transport stack, the selfcall mecha- '° PrtfpH!!!? Witt, <!i»te 

nism further ensures that for self-service requests, the upper ^° "^^^^ ^"'^ 

layer RPC processing, including parameter marshalUng/ Ifthe procedure contams static local variables whose state 

unmarshalling and RPC call setup, can be bypassed alto- ™" fu'^D^ ' ^"T^""' r"""^? "^'^ ""^ 

„^fu^^ ^; ™ v Same m both RPC and local procedure calls. 

gether to yield significant optimization. ^„ , ^„ ir^. r, • , ^ 

6. Procedure Allocated Persistent Server State m the Server 

Correctness Conditions for Selfcall Implementation ^5 Heap 

In the local case, the persistent memory that the procedure 

In order to ensure correct execution behavior, the follow- ,^^^,1^3 references as global state is visible to the 

ing description provides a discussion of program correctness wallers. However, since the references to the memory are not 

upon substituting a local procedure call for an RPC, as ^^^^ ^ack via parameters, the caller programs will nor- 

provided by the selfcall mechanism of the present mvention. j^^lly not be touched by the callers unless via global variable 

Aquestion may be asked at an abstract level: whether the reference. This scenario does not occur in a native RPC 

semantics of an application are maintained after switching application. So when the RPC is replaced with a local 

from an RPC to a local procedure call that invokes the same procedure call, there is no problem associated with global 

routine. This subtle question requires a clear understanding variable access. 

of how RPCs and local calls are different. Although RPC is 45 Hence, from this analysis, item #4 above is a condition 

known to have implemented a maximum local-remote that may cause program semantics to change when replacing 

transparency, it is not semantically completely identical to a an RPC with a local procedure call. This problem is resolved 

local call. by one of two methods: (A) interface checking and (B) 

The differences in an RPC and a local call lie in the enforcing a programming rule, 

memory management of the RPC client and the RPC server 50 A. Interface Checking and Auto -switching 

due to the inevitable physical separation of the two address The switching logic can detect the condition from the 

spaces. In RPC, there could be actual duplication of param- interface definitions prior to switching to local calls from 

eters in the client process heaps and in the server process RPCs. If the procedure contains an input "[in]" parameter 

heap, whereas in a local procedure call, there is only one which is a pointer to a structure, the optimization will not be 

copy of the parameters. This difference warrants a detailed 5S carried out. In this case, the RPC will be made, 

analysis. B. Enforcing a Programming Rule 

1. Input Scalar Data It is not good programming practice for the procedure to 
For RPC, a copy of the scalar is created in the procedure modify the structure that an "[in]" parameter points to 

stack. The copy is consumed and discarded at the return of knowing that the parameter will not be returned to the client, 

the call. The RPC and local call have the same semantics in 60 The only reason for doing so may be to use the stmcture a 

this scenario. temporary area when processing the data. This practice will 

2. Output Reference Parameters cause programming errors for local procedures when the 
For the local call the memory is allocated by the parameters are not expected to be changed by the procedure. 

procedure, and pointers to the memory are returned to the If a programming rule ensures no remote procedures will 

caller. 65 modify any non-scalar "[in]" parameters, the selfcall opti- 

For RPC, this means that the procedure will allocate mizalion can be realized in all situations without risking a 

parameter memory from the server process heap and the change in program semantics. 
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General Implementation of Selfcall the manager code handling an RPC in an RPC server makes 

c . T^i^ A n 1. ^ . 3 second RPC directed to itself, i.e. to the same server 

Wuh reference now to FIG^ 5A, a flowchart depicts a ^oth RPCs wiU use an RPC executor thread in that 

process for generating code for the selfcall mechamstn ^„ ^ 

dunng lDL compdafon m accordance wrih a preferred ^ call will have to wait. If all executor threads are doing this 

"".^I^^TnT , ^T^' """'""r; same thing, i.e.. are executing manager code that has made 

with the IDL compiler determimng that a selfcall option has ^ ^^^^ ^all to the same server, then a deadlock 

been specified by a user requesting the generation of self^ ^^^^ ^^^^^ ^ 

code when possible (step 502). The IDL compUer detects ,hreads that will never become available. 

appropnate conditions for ensunng correct behavior of a 

selfcall implementation with respect to the interface Technical Implementation of Selfcall in DCE 
description, i.e., determines whether selfcaUs can safely be 

made for a particular interface definition (step 504), The IDL ^ discussed previously, remote procedure calls are 

compiler then generates a different client stub that is capable implemented m a vanety of manners and distributed com- 

of switching the calls from RPC to local calls (step 506). P^^^^S environments, and the selfcall mechanism of the 

w/wt, «f^.^™ «^ i cTn sTi a u *^ •* present invention is applicable to all client-server distributed 
With reierence now to FIG. 5B, a flowchart depicts a . ... , , . . - 
r J • T . L . ■ systems which use remote procedure calls or a variation of 
process for executing code m the client process that is ^ , , „ f a r c 
^ ,1 ■ , f. ,o „ . . . remote procedure call as a foundation for communications 
capable of implementing the selfcaU mechanism in accor- i- . . ^n. r n • 
J ^ J u J- . r.u • ' among clients and servers. The foUowms description pro- 
dance with a preferred embodiment of the present mvention. J • 1 * *• J . 1 f .1. ir 11 u • r 
uir- c/^ ^^«;!.to o ™tu«^ r # • u* u r . vides implementation details for the selfcall mechamsm of 
MG. 5C depicts a method at client runtime m which a client on *u *• ^l- i j- . ^ . j 

, J .1. * u i_ 1 . J the present mvention within one particular distributed com- 

process executes code that has been previously generated ^^.^ model DCE 

using a process similar to that depicted in FIG. 5B. , * 

A, *i, 1- * ^ J * c i_- J f To enhance performance by avoiding the use of the 

At runtime, the client code determines from the binding if . *i n r . .i i 

11- J- *u • L. • u transport layer as well as the use of another executor thread, 

the current RPC call is directed to the same process in which ^ «ki^ f n a *■ ^- *i 

. , . • / . Tf 11 • 1- , a process should be able to call the function directly as a 

the client code is running (step 512). If the call is directed 25 ^^'i^t if .i,^ a ■ iu - *u 

, 1- . J r 11 iocal procedure call. It the runction is there m the same 

to the same process, the client code then performs a lookup ^ ^^j^ ^^^^ ^ 

,n the interface registry to get the local address of the ^„„^f,^^ 

manager function (step 514). The client code then converts „ . . .... 

the binding from a client-side binding to a server-side J^^ present invention recognizes that it would be more 

binding (step 516), and the local procedure call is made (step 30 '° '"^''^ ^ '"'^l' Pfoced"fe call when the procedure 

518). This step may need to be performed only once on the 'I" process by making changes to the client stub 

first call, with subsequent caUs using the converted binding \« ^'If^ " determined from the bindmg if 

obtained in the first call. If necessary, an authentication '^^'f"' ^ "f P'"'*^' " ^' 

process may be bypassed. "'^ "Herface registry is exammed 

„,... . , ___ . . ,c 'o g<5t the address of the procedure. The parameters for the 

With reference now to HG. 5C. a b ock diagram depicts 35 ^^^^^ ^^^^^ ^roccdaxc as they were 

a conversion of a remote procedure call to a local procedure j^j^ j^e client stub. In addition, the binding handle 

call withm a single process space. Process space 552 con- ^.^j be converted from a client-side binding to a server-side 

tains procedures on particular execu ion paths. At some binding since that is the way it would have been received in 

point, a routine or runction may mvoke remote procedure j^p^-. 

call 554. A normal RPC call passes through RPC stubs/RPC , , . . , . ,r „ u • 

runtime code 556 and through network transport code 558 to ™P}ement the selfcaU mechanism of the 

reach server procedure 560. However, since the server Present myention mthm DCE, three changes would be made 

procedure that is the subject of the RPC is in the same '° ""'^P'^^' '° suPP°rt f Ifcall. The first change 

process space as the routine that originates the RPC, the P™^'''''^ ^ "^,7' »s"-specifiable option that indicates 

present invention may convert the RPC, in certain « whether selfcall code should be generated^ Rather than 

circumstances, into local procedure call 562 via the selfcall always incorporating code that may switch RPCs to local 

mechanism calls, there may be times when a software developer does 

not want to take advantage of converting RPCs to local 

Identified Inefficiencies/problems With RPC in procedure calls, e.g., in particular software testing environ- 

DQ£ 50 tnents. Hence, the user may specify an option for generating 

selfcall code via a new command line option flag, an option 

One of the features of DCE is location transparency. An in a configuration file, etc. The IDL compiler accepts the 

application server can be located on any host in the network. option and stores the user preference in its option table along 

An application client docs not need to know the location of with other user-specifiable options, 

the application server beforehand. The directory service can 55 a second modification that would be required within an 

provide the location of an appropriate server, and RPC will jdl compiler is the addition of a function to the code 

deliver the call to that server. generator of the IDL compiler to generate the code to check 

RPC calls can be made from processes that are RPC whether selfcall is supported. The code generated by this 

servers, either from client threads or from manager code function is the same for any interface definition, 

running within an executor thread as a result of the server eo A third modification that would be required within an IDL 

receiving a client call. The RPC call can sometimes result in compiler to support the selfcall functionality of the present 

a call to the same server process. Hence, a first problem invention is the addition of a function to the code generator 

exists in that, under normal RPC processing, the client code of the IDL compiler to generate the code to call the manager 

does not know or care about the location of the server, and interface. The code generated by this function is different for 

a call IS made remotely, wasting resources and time. 55 each interface definition. ITie "manager" code or function is 

A second problem is that deadlocks can occur if there is the function or procedure that is the target of the original 

a limited number of executor threads to handle RPCs. When RPC call by the client process, whether or not the manager 
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function actually resides within the process that originates 
the RPC or resides within a server process elsewhere on the 
network. 

With reference now to FIG. 6A, a source code statement 
depicts a routine within the IDL compiler that has been 
enhanced to generate the code to check whether self call can 
be supported for a particular interface in accordance with a 
preferred embodiment of the present invention. 

As a preliminary step, the user has specified the desire to 
generate selfcall code. This may be achieved, for example, 
by allowing a user to specify a command line option 
parameter for selfcalls. The command line parser would 
have been modified to accept the selfcall option, which is 
then stored in the option table of the IDL compiler. 

When this option has been specified, a global flag would 
be set within the IDL compiler, such as "g_selfcair' shown 
in FIG. 6 A. The code generator of a standard IDL compiler 
has been modified so that when this flag is set, the IDL 
compiler wiU generate additional code in the client stub just 
before the call to "rpc_call_start", which is a standard 
function known to those skilled in the art. For example, the 
function "CSPELL_client_stub_routine( )" in the code 
generator of the IDL compiler, also known to those skilled 
in the art, is modified to include a statement similar to that 
shown in FIG. 6 A. The statement shows a check of the flag 
"g—selfcall" that reflects the selection by the user of the 
selfcall option in the IDL compiler. If the flag is set, then the 
function "CSPELL_selfcair' is caUed. 

The "CSPELL_selfcaH" function shown in FIG. 6A 
implements the second modification to the IDL compiler 
mentioned above. The "CSPELL__selfcall( )" function gen- 
erates the code which checks whether the RPC call can be 
handled locally, and if so, then this code calls the manager 
code directly. The call to the manager code is different for 
every interface. The call to the manager code is achieved by 
the function "CSPELL_manager selfcaU( as shown in 
FIG. 6B, which is called from the "CSPELL_selfcall( )". 

With reference now to FIG. 6B, a source code statement 
depicts a routine within the IDL compiler that has been 
enhanced to generate the code to make the manager function 
call in accordance with a preferred embodiment of the 
present invention. The "CSPELL_manager selfcall( )" 
function generates the code that uses the IDL_mgr_epv 
(entry point vector) to make the function call as it would be 
done in the server stub of this manager code during a 
standard RPC. The parameters passed to this function are the 
parameters that are passed to the client stub. Hence, it should 
be noted that it behaves as a true local procedure call, i.e., 
when the results are updated by the manager routine, the 
changes are made at the original address of the result 
parameters, while in a normal RPC the results are copied to 
the original address as a part of unmarsb ailing. As a result, 
the performance is enhanced. 

With reference now to FIG. 6C, a set of source code 
statements provides information about the changes that may 
be made to the client stub code to incorporate the selfcall 
mechanism of the present invention. The first call checks if 
the selfcall option has been specified, and if so, then the 
client stub attempts to implement the selfcall mechanism. 

In addition to the changes to the IDL compiler and the 
client stub code, the following changes are made to the RPC 
runtime in order to implement the selfcall mechanism of the 
present invention. A first routine, named "rpc_check_ 
selfcall", checks whether the RPC currently being processed 
call is directed to the same process that is making the RPC. 
It returns TRUE or FALSE, and if TRUE, it gets the address 
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of the manager code. A second routine, named "rpc_ 
binding_client_from__server", converts a client_side 
binding to a serve r_side binding, as shown in FIG. 6C. A 
third routine, named "rpc map exception lo__status", con- 
verts an exception to a status code so it can be handled like 
a status code received from an RPC. A fourth routine, named 
"rpc_network_ep_match", is called by "rpc_check_ 
selfcall" to see if the endpoint in a binding is one that is 
owned by this process. A fifth routine, named "rpc_ 
network_resolve_binding", lakes a partial binding which 
has an IP address but no endpoint and directly adds one of 
the endpoints owned by this process. 

The function "rpc_check_selfcaH" is called at the start of 
a client stub, as shown in FIG. 6C. Its purpose is to enable 
a client stub to determine whether a binding handle points to 
a server which is actuaUy the same process in which the 
client stub is executing and return the local address of the 
manager routine to be called. When this routine returns 
TRUE, the client stub calls the manager routine directly 
(locally) does not make the remote procedure call. This 
saves the overhead RPC setup and other processing and 
avoids the use of additional executor threads. 

A new "selfcall" flag has been added to the binding 
indicating whether the returned binding points to the same 
process that performs the function "rpc_check_selfcall" 
call. The flag's values are SELF, NOTSELF, and 
UNKNOWN. This flag is used in a manner such that the 
binding only has to be checked the first time it is used. 

To determine if the manager code can be called directly, 
the function "rpc_check__selfcaU" checks three things: 

1) whether this process is a server process; 

2) whether the binding points to this same process, i.e. 
whether the IP address matches one of the IP addresses 
on this machine, and whether the port number in the 
binding matches one of the port numbers owned by this 
process; 

3) whether this interfac6/obj„uuid pair is registered in the 
interface registry for this process. 

If one or more of these tests fail, this routine will return 
FALSE. No changes are made to the binding, other than to 
set the selfcaU flag to NOTSELF if either IP address or 
protocol/endpoint did not match. 

If all of these tests pass, the function will return a value 
of TRUE and pass an entry point vector back to the manager 
code so that the client stub can call the manager code 
directly. In the binding, the selfcall flag will be set to SELF 
and the bound_server_instance flag will be set to TRUE. 

If the binding was a partial binding, so that there is no 
endpoint to be used for comparison, and the other tests pass, 
an endpoint must be copied into the binding to resolve it into 
a full binding. 

RPC promises that all calls on a given handle bind to the 
same server instance. If a partial binding is passed in, the IP 
address matches, and the interface/obj_uuid match, the 
manager code could be caUed locally without resolving the 
partial binding. However, the partially bound binding could 
be resolved later to another server instance on this same 
machine, breaking the above promise. So the partial binding 
must be resolved into a fully bound binding before this 
routine returns TRUE. 

Referring to the three checks performed by the function 
"rpc_check_selfcall". as listed above, it should be noted 
that interface/obj_uuid is not checked first because, even if 
that check failed, the check would be done repeatedly as that 
binding was used again, without ever setting the selfcall flag 
in the binding. The selfcall flag in the binding is used to 
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return quickly from this routine for all calls after the first one 
when the call cannot be made locally. 

An attempt should be made to set the selfcall flag to either 
SELF or NOTSELF. However, there is one case in which it 
is not attempted. If a partial binding is received, and the 
interface/obj_uuid do not match, then the binding is not 
completed and the flag cannot be set. The routine "rpc_ 
check_selfcaU" returns, and normal RFC processing is 
attempted to complete the binding. In this case, a full 
binding wiU be available the second time it is checked, and 
the selfcall flag can be set to NOTSELE 

Conclusion 

The advantages of the present invention are apparent in 
view of the detailed description of the invention provided 
above. The present ; invention provides a short-circuiting 
scheme for RPCs. The technique automatically detects cer- 
tain conditions and switches an RFC operation to a normal, 
local procedure caU. 

In summary, the switch between an RFC and a local 
procedure call occurs when the RFC service request is 
serviced by the same server from which the RFC request is 
actually issued, a frequent occurrence in the DCE security 
server and other core infrastructure servers in distributed 
systems. This optimization eliminates the overhead of 
parameter passing, including parameter marshalling/ 
unmarshalling and transmitting over the transport media, 
which are involved in all distributed operations. In the case 
of authenticated RFCs in the DCE Security server, the 
overhead of authentication may also be eliminated since an 
RFC from the same process is already trusted. A secondary 
benefit of this technique is that it avoids a particular dead- 
lock situation in the DCE security server — when the server 
is under a heavy load, at which time all of the RFC work 
threads are busy and waiting on requests to the same server, 
an additional RFC cannot be serviced because no more work 
threads are available. This problem is usually encountered 
when a server makes. a call to a library routine that may call 
other library routines, and one of those library routines 
makes an RFC call to that same server. 

In an exemplary implementation, the IDL compiler uses 
information about the nature of the procedure being called 
through RFC in order to generate client stub code that is able 
to switch from an RFC to a local procedure call. For a 
normal RFC, the IDL compiler uses an interface definition 
to generate code for the client stub and for the server stub. 
The present invention takes advantage of the fact that the 
IDL compiler can generate client stub code for calling a 
target procedure locally (when appropriate) in a manner 
similar to code in ihe'server stub that would be generated by 
the IDL compiler for calling the target procedure in the 
server process during a standard RFC, 

It is important to note that while the present invention has 
been described in the context of a fully functioning data 
processing system, those of ordinary skill in the art will 
appreciate that the processes of the present invention are 
capable of being distributed in a form of a computer readable 
medium of instructions and a variety of forms and that the 
present invention applies equally regardless of the particular 
type of signal bearing media actually used to carry out the 
distribution. Exampl9s of computer readable media include 
recordable-type media such a floppy disc, a hard disk drive, 
a RAM, and CD-ROMs and transmission -type media such 
as digital and analog communications links. 

ITie description of the present invention has been pre- 
sented for purposes of illustration and description, but is not 
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intended to be exhaustive or limited to the invention in the 
form disclosed. Many modifications and variations will be 
apparent to those of ordinary skill in the art. The embodi- 
ment was chosen and described in order to best explain the 
5 principles of the invention the practical application and to 
enable others of ordinary skill in the art to understand the 
invention for various embodiments with various modifica- 
tions as are suited to the particular use contemplated. 
What is claimed is: 

1. A method for calling a service procedure from a client 
process residing on a host computer in a distributed data 
processing system, the method comprising the steps of: 

in response to a remote procediire call (RFC) by the client 
process for the service procedure, detecting whether the 
service procedure is provided by the client process; and 

in response to a determination that the service procedure 
is provided by the client process, calling the service 
procedure using a local procedure caU. 

2. The method of claim 1 wherein the step of detecting 
whether the service procedure is provided by the client 

20 process further comprises: 

obtaining a binding handle of a server process for the 

service procedure; 
determining whether the binding handle of the server 
process points to the client process; and 
25 in response to a determination that the binding handle of 
the server process points to the client process, provid- 
ing a positive indication that the service procedure is 
provided by the client process. 

3. The method of claim 2 wherein the binding handle 
30 specifies a network address and a port number. 

4. The method of claim 2 further comprising: 
converting the binding handle of the server process from 

a client-side binding to a server-side binding. 

5. The method of claim 1 wherein the step of calling the 
35 service procedure further comprises: 

obtaining a local address for the function within the client 
process; and 

executing code for the service procedure at the local 
address. 

40 6. The method of claim 5 wherein the step of obtaining the 
local address further comprises: 
looking up the service procedure in an interface registry. 

7. The method of claim 1 further comprising: 
initiating the RFC; 

45 invoking a client stub for the service procedure; and 

passing parameters received by the client stub to the 
service procedure in the local procedure call. 

8. The method of claim 7 wherein code for the client stub 
was compiled by an Interface Definition Language (IDL) 

50 compiler in accordance with predefined conditions. 

9. The method of claim 7 wherein code for the chent stub 
does not marsball and unmarshall the parameters. 

10. The method of claim 1 wherein the RFC executes 
using a send and receive message facility of an operating 

55 system on the host computer. 

11. A data processing system for ca fling a service proce- 
dure from a client process residing on a host computer in a 
distributed data processing system, the data processing 
system comprising: 

60 detecting means for detecting, in response to a remote 
procedure call (RFC) by the client process for the 
service procedure, whether the service procedure is 
provided by the client process; and 
calling means for calling, in response to a determination 

65 that the service procedure is provided by the client 
process, the service procedure using a local procedure 
call. 
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12. The data processing system of claim 11 wherein the service procedure from a client process residing in the data 
detecting means further comprises: processing system, the computer program product compris- 

first obtaining means for obtaining a binding handle of a ing the steps of: 

server process for the service procedure; instructions for detecting, in response to a remote prece- 
de termining means for determining whether the binding ^ dure call (RFC) by the client process for the service 
handle of the server process points to the client process; procedure, whether the service procedure is provided 
and by the client process; and 
providing means for providing, in response to a determi- instructions for calling, in response to a determination that 
nation that the binding handle of the server process the service procedure is provided by the client process, 
pomts to the client process, a positive indication that the service procedure using a local procedure call. 
. J^I.^^'y''^^ procedure is provided by the cUent process. 22. The computer program product of claim 21 wherein 

13. Th, data processmg system of claim 12 wherein the instructions for detecting whether the service procedure 
iumbe^ ' ' ^""'^ is provided by the client process further comprises: 

14. The data processing system of claim 12 further instructions for obtaining a binding handle of a server 
comprising: process for the service procedure; 

converting means for converting the binding handle of the instructions for determining whether the binding handle 

server process from a client -side binding to a server- of the server process points to the client process; and 
side binding. 20 instructions for providing, in response to a determination 

15. The data processing system of claim 11 wherein the that the binding handle of the server process points to 
calling means further comprises: the client process, a positive indication that the service 

second obtaining rpeans for obtaining a local address for procedure is provided by the client process. 

the function within the client process; and 23. The computer program product of claim 22 further 

executing means for executing code for the service pro- comprising: 

cedure at the local address. instructions for converting the binding handle of the 

16. The data processing system of claim 15 wherein the server process from a client-side binding to a server- 
second obtaining means further comprises: ^^^^ binding 

lookup means for looking up the service procedure in an 24. The computer program product of claim 21 wherein 

interface registry. the instructions for calling the service procedure further 

17. The data processing system of claim 11 further comprises: 

compnsmg. .... instructions for obtaining a local address for the function 

initiating means for initiating the RPC; jj,^ ^y.^j p^^,^^. 

'""^fitdrnTTd" ' '''^'^ instructions for executing code for the service procedure 

* ^ at the local address, 

passing means for passing parameters received by the 25. The computer program product of claim 24 wherein 

client stub to the service procedure in the local proce- the instructions for obtaining the local address further com- 

durecall. prises: 

18. The data processing system of claim 17 wherein code 40 • , j , , . ^. . , . 

f *u 1**1. M J i_ T . ^ II • • instructions for looking up the service procedure in an 

tor the client stub was compiled by an Interface Definition interface re istr 

Language (IDL) compiler in accordance with predefined n£ ^ * j * r i n ^.i. 

conditions 26. The computer program product of claim 21 further 

19. The data processing system of claim 17 wherein code compnsmg. 

for the client stub does not marshaU and unmarshall the 45 instructions for imtiatmg the RPC; 

parameters. instructions for invoking a client stub for the service 

20. The data processing system of claim 11 wherein the procedure; and 

RPC executes using a send and receive message facility of instructions for passing parameters received by the client 

an operating system on the host computer , stub to the service procedure in the local procedure call. 

21. A computer program product in a computer- readable so 

medium for use in a data processing system for calling a * * * * ♦ 
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